Latest news (2004-07-06)

One week in our new office, things are starting to settle down... Finally throwing together something that resembles a comprehensive update, though I'll probably run out of steam before I get to everything. (Several hours pass)... Quite a lengthy changelog, but with even more to come in the following days. I ran out of steam around the capture card section, which needs lots of love (like some PVR-350 X driver stuff, multi-ivtv card config stuf, change paths from mythtv 0.14 to 0.15.1, etc). Still not moving to Fedora Core 2 (no stable FC2-clean ivtv drivers), but that's on the horizon as well. Now I'm badly in need of sleep...

Please check the changelog for more details on what has changed.

--jarod

Step-by-step guide to building a MythTV System on Fedora Core w/ATrpms

TABLE OF CONTENTS:

1. Introduction
2. Hardware
3. Initial Software
4. Firstboot setup -- create MythTV user and enable ntp
5. Install Ethernet Driver (nForce2 boards only)
6. Get and install apt, update your OS packages
7. Get and install custom ATrpms kernel
8. Get and install video card drivers
9. Get and install ALSA
10. Get and install MythTV
11. Get and install capture card drivers
12. Get and install lirc
13. Set up MySQL
14. Set up MythTV
15. Configure automatic startup
16. Configuring MythTV add-ons
17. Upgrading your system
18. Miscellanea
19. Changelog

1. Introduction

MythTV is an open-source project, with its primary functionality being similar to that of TiVo, but with several way-cool add-ons and much greater flexibility. The project's founder and leader is Isaac Richards. The official documentation can all be found on MythTV's official web site, at http://www.mythtv.org/. The project is supported by the contributed time and effort of the open-source community, with the primary lines of technical support being the documentation on the project web site, and the project's mailing lists. It is highly recommended that if you are intending to install MythTV, join at least the mythtv-users mailing list, which you can subscribe to here: http://www.mythtv.org/mailman/listinfo/mythtv-users/, and read through the official docs.

While the official documentation attempts to be as distribution-agnostic as possible, this document is geared specifically toward building a MythTV system on the Linux distributions put out by Red Hat. Quite a few people following this particular body of documentation have successfully created their own MythTV systems, and many of them frequent the mailing list. They can generally help you if you have a problem. I also frequent the mailing lists, and will help out in any way I can. However, please search the mailing list archive, found here: http://www.gossamer-threads.com/lists/mythtv/, before you mail the list, because there is a good chance you'll find your answer there. If you are unable to find the answer there, then read this document: http://catb.org/~esr/faqs/smart-questions.html, after which you may address your question to the mailing list. ;-)

It was suggested to me by a number of folks that I provide PayPal account information for those wishing to contribute. The fund for a PVR-350 has already matured, I've bought it, got it up and running, and have since committed my experiences to this document. The latest round of funding is going toward the purchase of a PVR-350 for Axel Thimm, the maintainer of ATrpms, as a thank you for all the packaging work he's done, upon which this guide relies heavily. The card for Axel is now paid for. I think the next purchase drawn from the fund will be a new NV4X-series card from nVidia, once they see the light of day... Certainly don't feel obligated, but go ahead and click on the little PayPay button if you feel inclined. =)

Anyhow, I try to answer any email I get, but I can't always keep up. I often get some of them the same questions/problems over and over, so chances are, someone on the list can answer your question, even if you don't find what you needed in the mailing list archive, and you'll likely have a solution faster than I can respond. If you think you've found a problem with something in this document, or have a suggestion for an improvement, please don't hesitate to contact me directly via email. I try to keep this document as up to date and accurate as my time permits.

Also, please note: most of what is in here should apply equally to Red Hat Linux 9, just change the package version numbers and distro tags accordingly. Much of this should apply equally to RHL8.0 and 7.3 as well, but you'll have to upgrade your qt packages to 3.1+ for MythTV 0.13+ compatibility, which I'm not covering. While definitely very Red Hat-centric, a fair amount of the information here should apply to MythTV installed on just about any variant of Linux.

Thank you, and enjoy!
--Jarod C. Wilson, RHCE
<jcw@wilsonet.com>

2. Hardware

I suggest you start here for information on hardware:

On top of the hardware requirements described there, this document assumes you've got either a Hauppauge WinTV PVR-x50, AVerMedia M179, or a bt8x8-based capture card. I also have a pcHDTV card, but no time right now to do a full write-up. This document DOES now cover PVR-350 TV-Out, thanks to donations to purchase one. Also note that this document assumes both the MythTV frontend and backend are on the same machine, though I do have a bit of info on setting up a remote frontend in the Miscellanea section.

Just about any computer that runs Linux and has enough processing power can be used as a MythTV box. For reference, here are the specs on the production systems of both Christopher and I:

Jarod's Master Backend System:

• Case: Dell OptiPlex GX300
• PSU: Dell-provided
• Motherboard: Dell dual Pentium-III
• CPU(s): dual Pentium-III @ 733MHz
• RAM: 256MB RDRAM
• Hard Drive(s): 7200rpm ATA/100 250GB Western Digital Caviar SE (8MB Cache) for video, 5400rpm ATA/100 40GB Western Digital Caviar for OS & network-boot images
• Optical: Panasonic DVD-ROM
• Video Card: nVidia TNT2
• Sound Card: Onboard
• NIC: onboard 3Com
• Video Capture Card #1: Hauppauge WinTV PVR-250
• Video Capture Card #2: AVerMedia M179

Jarod's Primary Frontend System:

• Case: CoolerMaster ATC-620C-BX1 (black desktop micro-ATX)
• PSU: Enermax Whisper Series EG365P-VE 350W (adjustable fan speed for low noise operation)
• Motherboard: Chaintech Summit 7NIF2 (nForce2-based micro-ATX)
• CPU: AMD Athlon XP 3200+ w/400FSB (overkill for most systems, but not for HDTV)
• RAM: 512MB DDR-333 (PC-2700)
• Hard Drive(s): 7200rpm ATA/100 120GB Western Digital Caviar
• Optical: Black bezel 16x Sony DVD-ROM
• Video Card: Onboard GeForce 4 MX (64MB shared system memory)
• Sound Card: SoundBlaster Audigy (OEM)
• NIC: Onboard nForce2 LAN (driver not included w/FC)
• Video Capture Card: pcHDTV HD-2000

Jarod's Secondary Frontend System:

• Case: Travla C137 (the black one)
• PSU: external supply included w/case
• Motherboard: VIA EPIA M10000
• CPU: VIA C3 @ 1.0GHz
• RAM: 256MB DDR-266 (PC-2100)
• Hard Drive(s): none
• Optical: none
• Video Card: Hauppauge WinTV PVR-350 TV-Out
• Sound Card: Onboard
• NIC: Onboard VIA Rhine-II LAN
• Video Capture Card: Hauppauge WinTV PVR-350

Christopher's Production System:

• Case: ASUS Pundit
• PSU: Included with Pundit
• Motherboard: ASUS P4S8L
• CPU: Intel Celeron 2.0GHz
• RAM: 512MB DDR-333 (PC-2700)
• Hard Drive: 7200rpm ATA/133 200GB Maxtor
• Optical: Sony DRU-500AX DVD+RW/DVD-RW/CD-RW/DVD-ROM/CD-ROM
• Video Card: Onboard SiS 315 Integrated Graphics
• Sound Card: Onboard AC '97
• NIC: Onboard Broadcom BCM4401 (driver not included w/FC)
• Video Capture Card: Hauppauge WinTV PVR-250

A good place to look at other examples of what people are using for their MythTV boxes, and how they rate their systems, is Mark Cooper's PVRHW database, browseable here:

Pundit users might also find Matt Marsh's "Pundit MythTV Device" site of use:

Also note: the WinTV PVR series and AVerMedia M179 cards may have issues running correctly on some motherboards based on VIA chipsets. Check the ivtv FAQ to see if your chipset is on the list of known offenders:

3. Initial Software

This guide is geared toward using Red Hat's Fedora Core 1 Linux distribution, but most of the steps are applicable to any recent offering from Red Hat (Red Hat Linux 9, 8.0, 7.3, and to some extent, Fedora Core 2), though you may have additional dependencies to install and the package versions will be different. I'm not shifting this document to Fedora Core 2 until there are stable ivtv drivers that work with the stock FC2 kernels. You can download the iso CD images for Fedora Core (1 and 2) from one of the many Red Hat mirrors out there, the official list of which can be found here:

Perform a custom installation of Fedora Core 1, selecting (at least) these package groups:

• X Window System
• KDE Desktop Environment
• SQL Database Server (selecting only mysql-server under the "Details" section)
• Kernel Development (if you want/need to compile any of your own drivers)
• Web Server (if you want to use MythWeb)

Some other packages that might be of interest, but are not required:

• Graphical Internet
  • Gaim
  • Mozilla (very handy for following this very guide -- think copy and paste)
• Sound and Video
• Windows File Server
• Network Servers
  • vnc-server

Also, I *highly* recommend a custom partitioning scheme, rather than auto-partitioning. Having all your video storage on a dedicated partition will make life much easier if you ever want to nuke the OS. Just don't reformat the video partition, and all your video files will remain. This also makes it easier to convert your video filesystem to another format, like XFS or ReiserFS. A suitable custom partitioning setup is as follows (assuming a single IDE hard drive):

Make a note of what partition /video is (/dev/hda5 in this example) for future reference...

As suggested on the MythTV site, we're going to use KDE as our X environment for running MythTV. If you happen to be running another window manager, you can fire up a terminal session, and issue the command:

Or, you can try your luck with another window manager. Others will work, but this doc is geared toward using KDE. As an aside, I've used MythTV under Gnome 2.2 with Red Hat Linux 9 and under Gnome 2.4 with Fedora Core, both without issue. I'm contemplating a switch to XFCE4 myself, which I'll likely document and post as an alternative. Jim Chandler has already done something similar with WindowMaker, and contributed these notes (I still intend to try them out myself, but haven't had time).

4. Firstboot setup -- create MythTV user and enable ntp

At the first boot setup screen, create a user called mythtv, with a password of your choosing. All further documentation assumes you are logged in as the user mythtv. Lines with $ as the prompt are executed as user mythtv, lines with # as the prompt are executed as root. You should NEVER log in to your machine directly as root. Log in with the normal user account, then assume root privs with 'su' wherever a command needs to be run as root.

For the beginners out there, type 'su' (without the quotes) then hit return, and you'll get prompted for the root password. After entering that, you'll have a root prompt. Do what you need to do as root, then type 'exit' (again, without the quotes) to get back to your normal user prompt.

In that same first boot setup area, there is an option to enable ntp. This is highly recommended. You want your shows to start recording at the right times, don't you? ;-) Check the box to enable ntp, and either enter an ntp server you know of near you, or just go with pool.ntp.org, which is a dns alias that will try to find an ntp server in your vicinity.

5. Install Ethernet Driver (nForce2 boards only)

Fedora Core 1 actually includes the NIC driver for the Pundit, so building your own is no longer necessary. Prior versions of Red Hat Linux do require you to build your own NIC driver for the Pundit. Drivers for nForce2 onboard ethernet controllers are not included in Fedora Core 1, so you've got a little work to do if you're running on one (but its worth it ;-). Fedora Core 2 includes the open-source forcedeth driver for nForce2 boards, so this step will disappear in due course...

Rather than mess with nVidia's binary ethernet driver, which is part of this big messy glob that includes audio and usb drivers as well, I went with the forcedeth driver, which has been back-ported from the 2.6 kernel tree and packaged on ATrpms. In reality, my nForce2 system now actually runs Fedora Core 2 and a 2.6 kernel, but I used the back-ported forcedeth for some time before upgrading to FC2.

Anyhow, you'll have to download the forcedeth driver from ATrpms and get it onto your system somehow... Obviously, you'll either need another machine with which to download them (then burn the files to a CD or put them on a USB thumb drive), or a spare NIC to put in your nForce2 system temporarily (I used a spare NIC). You can find the latest version of the drivers here:

Given that kernel modules don't exist for the original FC1 kernel, you'll have to do a bit of leg work to get the driver installed... The easiest thing to do is download the latest kernel (currently 2.4.22-1.2197.nptl_51.rhfc1.at and matching kernel-module-forcedeth packages (kernel-module-forcedeth-2.4.22-1.2197.nptl_51.rhfc1.at.*.yourarch.rpm and forcedeth-*.rhfc1.at.i386.rpm). Install the kernel, then install both forcedeth components and reboot your system. Kudzu should now be able to find the onboard ethernet controller and configure it.

NOTE: obviously, since you just installed the latest ATrpms kernel, ignore the part in step 7 about installing a kernel, but take note of the environment variable stuff.

6. Get and install apt, update your OS packages

This will make life MUCH easier!

Install Axel Thimm's ATrpms-kickstart from http://atrpms.net/dist/fc1/atrpms-kickstart/. This provides you with apt and a pre-configured set of apt repositories, which include everything we'll need.

NOTE: the version number for the atrpms-kickstart package may be different when you read this, in which case you'll have to download it manually, and install from a local package.

Now update the apt package list and kick off an upgrade of all your installed rpms (this will take a while, lots of packages to download):

WARNING: Do NOT do attempt any other rpm activity while the upgrade is in progress. Performing multiple exclusive rpm operations at the same time can lead to very bad things happening (rpm database inconsistencies, race conditions, etc). After the big upgrade, you MAY get an error about being unable to open the rpm database (this used to happen to me w/RHL9, but hasn't ever with FC). If you do encounter this error, try the following:

Note that the rebuilddb will take quite a while to complete. After it completes, you'll see an error message, but you can safely ignore it and move on to see if the rebuilddb cleared the problem. If not, good luck...

BIG, FAT, IF YOU MISS IT, I WILL SCOLD YOU, WARNING[1]: To get your installation to go off without a hitch, you need to comment out the apt.kde-redhat.org and kde-redhat.atrpms.net entries in /etc/apt/sources.list (simply place a # in front of all kde-redhat lines), then pull one more update to get your local apt metadata cache fully updated to proceed with the installation:

However, if you are crafty, you can work out the dependency problems with the kde-redhat repo (search their site/mailing lists at kde-redhat.sourceforge.net, I can't recall the work-around), and end up with a very nice KDE 3.2 desktop, which is what I'm currently running on my FC1 workstation (didn't bother for my Myth boxes though, next desktop environment change for me will be to try XFCE4, if I ever get the time).

You might also want to install Synaptic, a graphical frontend to apt, which you can use in place of the command line if you prefer.

Note that Axel maintains several different channels of rpms, with varying stability labels on them. Most of the packages used in this document are classified as "testing" or better, meaning at the very least, they've been tested by a few people and found to work just fine. The only channel to *really* watch out for is the "bleeding" channel. If you enable it, you've been warned; things may break. You're on your own to fix 'em, so be prepared (Axel appreciates bug reports though!). The classifications are as follows (from Axel's web site):

For those that are attempting this installation using apt, but without installing the atrpms-kickstart package, note that you'll have to do some editing of your apt repositories. At a minimum, you need to be set up to use the ATrpms repositories and the FreshRPMs repository, as a number of dependencies for various MythTV components, as well as core OS updates, are pulled from FreshRPMs.

7. Get and install custom ATrpms kernel

While everything in this guide CAN be done using the stock Fedora Core kernels, Axel has also prepared a kernel that is properly patched for use with v4l2 devices (like the PVR-x50/M179), and has a number of other added features (XFS, a very good file system large files, low-latency patches, etc...).

Install his latest kernel package (as of this writing), like so:

Those wanting to build any of their own stuff, like lirc or ivtv drivers, you'll also want the matching kernel-source package (not required for most installations anymore):

*Check http://atrpms.net/dist/fc1/kernel/ to make sure you are using the most up to date kernel. If you are using an older kernel, the very latest kernel modules likely won't be available.

Now edit /boot/grub/grub.conf, changing default=1 (or whatever it is) to default=0, so your new kernel is the default boot kernel, and reboot!

Following the reboot, we're going to set up a custom environment variable that will make life easier when installing kernel modules via apt. With the latest change in kernel module naming conventions (a coordinated effort between ATrpms, DAG, FreshRPMs and a few other rpm repositories), all systems can simply use this environment variable, like so:

Please note: this variable will NOT survive a reboot, so if you reboot, you'll have to set it again. It is merely a short-hand convenience for the install procedure, not something that is present by default.

WARNING: There is a minor, inconsequential, feel-free-to-just-ignore-it error message with the ATrpms kernels, regarding a powernow-k7.o module with some unresolved symbols. While annoying, it doesn't cause any problems, so you can safely ignore it for now.

8. Get and install video card drivers

While Fedora Core includes video drivers for most video cards, they aren't always the best ones for the needs of a MythTV user. For example, many video cards require experimental 3rd-party or proprietary drivers to enable TV-Out. Without nVidia's own proprietary video drivers, the performance of cards based on their chipsets will suffer greatly, even if you aren't using TV-Out. Instructions for installing accelerated drivers for nVidia and SiS cards can be found below. You're on your own for other cards.

For users of the PVR-350's TV-Out:

Initially, you'll need another video output device hooked to a display in order to configure the PVR-350's TV-Out, unless you're extremely comfortable at the command line, in which case you can simply ssh into your PVR-350-equipped box. I actually did all the setup of mine while the computer was connected to my TV via TV-Out on my GeForce 4 MX, in run-level 5. That way, I had a shell window and a browser window open, so I could easily cut and paste. Further instructions for configuring the PVR-350 can be found in section 11.

For users of nVidia Video Cards:

As of June 30, 2004, nVidia has finally released a long-overdue driver update, 1.0-6106, that restores almost all the functionality broken in driver releases after 1.0-4363. This driver restores overscan functionality last seen in 4363, but retains the superior OpenGL performance of later drivers. However, the /dev/nvidia0 functionality from 4363 used for Myth's experimental vsync code is still non-existent (though the latest Myth code base has some OpenGL-based work-arounds that are almost as good). Oh yeah, this version will also work with the stock Fedora Core 2 kernels (prior versions weren't clean for use with the 4kstacks feature in recent 2.6 kernels, including Red Hat's). I'm going with 6106 now myself, but some folks may still have better luck with 4363.

Anyhow, to make life easier, Axel has prebuilt kernel modules for use with both the latest Fedora Core 1 stock kernels and his custom kernels. Install for your active kernel like so:

Simple replace the 6106 with 4363 above, and you can install the older version instead. Note that you can actually have multiple versions installed, and switching between them is as easy as:

This latest revision of the nvidia rpms inserts a necessary line into modules.conf, and generates an XF86Config file for use with the nvidia driver, based on your initial XF86Config file. This new file is saved as /etc/X11/XF86Config.nvidia, and after peeking through it to make sure it looks appropriate, drop it into place. I suggest backing up the original file, and keeping a copy of the initial nvidia version, just for good measure.

Add Load "v4l" in the "Module" section near the top of your XF86Config file, for optimal v4l to X video transfer and v4l picture control.

If you're in X right now, simply log out to relaunch X with the new configuration. If you're at the command line, either switch to run-level 5 ("init 5") or run "startx". Once you've verified this configuration is working, you'll likely want to look into the additional options below, to enable TV-Out, accelerated rendering, etc.

Here's an example Device setup section for a GeForce 4 MX video card using the 1.0-6106 nvidia driver to output to an NTSC television via S-Video (this should work equally for any GF4 or FX series card, as well as GF2/3, minus TVOverScan):

Those with particularly cantankerous displays and/or people who want to pass their signal through an A/V switchbox may have problems with their card/drivers not auto-detecting the attached display type, in which case, you can add an Option line to the above Device section to force the display type, such as this one:

You will likely have to tweak the TVOverScan option value to best suit your TV. Valid values range from 0.0 (no overscan) to 1.0 (overscan as much as possible). This helps to eliminate a black border from showing up around the picture on your TV. Again, note that overscan is only supported on GeForce4-class (or newer) video cards, but all other options should work for earlier nVidia cards. Obviously, your settings may vary slightly, depending on your card.

Note: overscan is possible with some older nVidia cards, as well as some 3Dfx cards, by using nvtv, which but you can find here:

My secondary MythTV system had a GF2MX until it was recently upgraded, with which I was using nvtv to blow the picture up a bit. It did a fine job. I'll add something on that when I get a chance, if I can remember what I did, now that I've junked the GF2MX...

There are a few settings not explicitly specified in the above configuration, as most of them can be auto-detected. However, it is possible you'll have to force some settings if auto-detection doesn't work. All these options are well-documented on nVidia's web site in the documentation files available in the Linux driver download area (http://www.nvidia.com/view.asp?IO=linux).

Also, if you are having issues with video performance, there are reports that some chipsets don't let nVidia cards play nice with the nvidia driver using the kernel's agp driver, so try enabling nVidia's own agp driver. Other folks not having any problems have also reported a perceptible improvement in video quality and smoothness using nVidia's agp driver. You can enable it by adding this line to the above "Device" section of your setup:

And of course, there are some setups that don't like nVidia's agp driver, so just yank that line back out if you find that to be the case. I'm currently using NvAGP on my system without issue.

To make it even more interesting, some people have system stability issues if they use the RenderAccel option, so if you run into stability issues, you may try removing the RenderAccel line from my config snippet above.

For reference, and because many people have asked, I'm posting full copies of the XF86Config files from both my primary and secondary systems. My primary system uses a custom 960x540p mode to output to a High-Definition TV through an Audio Authority 9A60 VGA to Component Video converter. I used to feed this set via S-Video, and while the picture was good, it can't touch the progressive-scan signal I'm now feeding the HDTV. My secondary system outputs via S-Video to a plain old 27" analog TV.

For users of the Asus Pundit w/onboard video:

The Asus Pundit's onboard video controller is made by Silicon Integrated Systems. Accelerated video is not supported by Fedora Core's native video driver. You'll want to obtain the binary SiS driver, or MythTV performance will suffer greatly (and TV-out won't work right).

Use wget to get the binary SiS video driver

Note: http://www.winischhofer.net/linuxsisvga.shtml also lists a SiS Display Control Panel, which might be of use, especially for folks that need to tweak their display settings a bit and don't want to deal with command-line text-file hacking. I've used it myself, and it certainly is a handy tool. You can adjust overscan and underscan, flicker reduction, display mirroring, etc., all on the fly without restarting X.

Now run the redhat-config-xfree86 utility to change the video driver.

Choose the 'Advanced' tab, then press the 'Configure' button for the video card type.

Choose the 'SiS 630' card. This will set the driver to 'sis'. Also click on 'Custom memory size' to the value you have set in the BIOS (8 to 64M).

Press the 'Ok' button, then press the 'Ok' button again.

Log out of your X session (if you had one active) and log back in for the settings to take effect.

Here is an example /etc/X11/XF86Config 'Device' section for the ASUS Pundit:

And finally add Load "v4l" in the "Module" section near the top of your XF86Config file, for optimal v4l to X video transfer and v4l picture control.

9. Get and install ALSA

For starters, let me say that aRts (the KDE sound server) does NOT work well with MythTV in many cases, though work has been done recently to remedy that. It is still highly recommended that you disable aRts from starting up. To do so, while logged in as your mythtv user, choose "Control Center" off the Fedora (Red Hat) menu. Navigate through "Sound & Multimedia" to "Sound System" and deselect "Start aRts soundserver on KDE startup" and then click "Apply". On subsequent logins, aRts will not launch.

Please note: the rest of this step is not essential. It is possible to get MythTV working without touching ALSA. Fedora Core's included OSS audio framework generally works fine. It occasionally has issues, and ALSA is generally superior in sound quality and features, but I did have my system working without ALSA. One HUGE reason I wanted ALSA was so I could use the digital coax output on my SoundBlaster Audigy sound card to feed my amp a digital coax S/PDIF signal, which I couldn't do with OSS (at least not without a CVS version of OSS and the addition of emu-tools, but that's a story for another time).

That said, and still assuming you want to attempt an ALSA install, the easiest way is to use apt:

Optionally, you may also want to install the gnome-alsamixer, as it is a bit easier to work with than the cli alsamixer, and tends to better cover all your card's features than KDE's kmix (it works just fine in KDE also, despite the Gnome name):

Typically, the Fedora Core installation process will have detected your sound card and inserted some module configuration lines for the legacy OSS audio drivers in /etc/modules.conf (the nForce2 driver installation may have also made some edits). Make sure to remove them, or you'll end up trying to load multiple drivers for the same device (not a good thing). The lines I had to remove for my Audigy were:

At this point, I would recommend rebooting, just to be safe. That way, you know for sure you don't have the old OSS sound modules loaded. However, it is possible to do this without a reboot, which in my case, required the commands below, but will vary from sound card to sound card:

If you rebooted, remember to reset the $MYKERNEL environment variable:

On with ALSA... The ALSA drivers have reached 1.0 status (concurrent with the final 2.6.0 kernel release, in which ALSA is now the default audio subsystem). The currently available rpms now includes a VERY nice little utility by the name of alsaconf. It's a nifty little program that will attempt to discover all the sound cards in your system and insert the necessary lines into /etc/modules.conf.

However, for me anyhow, it only seems to work for one card at a time (trying to add another card results in replacement, rather than addition). The good news is that it does seem to get the settings correct for that one card, meaning you don't have to do much manaul editing of /etc/modules.conf to get ALSA working. Simply run this:

If you have multiple sound cards you want to use, and/or alsaconf just doesn't work for you, you'll have to edit your /etc/modules.conf file for your specific card. Details for supported cards can be found here:

I'm including a copy of my /etc/modules.conf ALSA configuration excerpt, which is for a SoundBlaster Audigy sound card. This should be valid for SB Live! and Audigy2 cards as well. If your card isn't one of those, check out the ALSA site's sound card matrix to find information for your card. The differences are very minor for most cards, and usually only the 'alias snd-card-0 snd-emu10k1' line has to be changed. For example, to configure ALSA for use with the onboard audio of an nForce2 board, it should be a simple matter of replacing all instances of "emu10k1" in the following modules.conf and .asoundrc with "intel8x0".

For those folks out there unfortunate enough to need dual sound cards, I'm including my modules.conf ALSA snippet from when I was doing just that, with a SoundBlaster Audigy and nForce2 onboard audio. You are on your own for figuring out dual mixers, dsp devices, etc...

Next, create a .asoundrc file for your mythtv user (full path of /home/mythtv/.asoundrc). Just make a new text file called .asoundrc like so (adjust for your specific card):

Now fire up the audio controller of your choice (aumix, alsamixer, kmix or gnome-alsamixer) and adjust the volumes to your liking. The alsaconf utility will have set your volumes to reasonable levels to start out, but you'll likely have to tweak things to achieve optimal sound, epecially if you're using something like S/PDIF out. While enabling S/PDIF out for my Audigy was a matter of a checking a box in gnome-alsamixer, some folks have reported having to set a particular slider to zero to enable the S/PDIF output on certain (non-Creative) sound cards. Go figure.

After you have the sound drivers loaded and everything configured to your liking, you should store the settings with the command:

That will let you mess with your settings all you want after saving them, and always be able to fall back to a known good setup. Run it again if you make further changes you want to save.

To go along with that, it might be nice to also restore your settings when the machine reboots. The easiest way to make sure this happens is to append a line to rc.local:

A simple way to test whether or not you've got sound is to use ALSA's aplay utility, like so:

10. Get and install MythTV

Now, here's why we REALLY like apt... MythTV has several dependencies to install correctly, which apt automatically takes care of with one simple command:

The last time I looked, that one-liner installed 54 different packages. Just a wee bit easier than hunting down everingthing by hand, let alone compiling everything... :)

If you get some error about failed dependencies, package conflicts, etc., with gtk2, gtk+, redhat-artwork, or something like that, please refer to the big fat warning back in section 6...

11. Get and install capture card driver

For WinTV PVR-250/350/Freestyle and AVerMedia M179 capture card users-

Disclaimer! The ivtv driver for these capture cards is still considered beta, though it does work quite well. Driver development isn't entirely stable just yet, and thus parts of this section may become obsolete over time. But on with the show!

Install the ivtv driver components, like so:

This has been broken down into multiple lines, due to apt flat-out not cooperating when it comes to dependency resolution (multiple kernel modules will satisfy the deps of ivtv, but it seems to like to install something other than the one we want, unless we install the one we want first).

Note: 21288 is the firmware version I'm currently using in my primary production system with both a PVR-250 and M179. My secondary system with a PVR-350 in it is also using this firmware revision. However, others have reported problems using this firmware version, but success with older versions (that, of course, gave *me* problems...). Whether it is signifcant or not, I'll also add that my M179 is now /dev/video0 and my PVR-250 /dev/video1. Anyhow, you can find both some newer (beta) firmware and older firmware to experiment with here:

Now, edit /etc/modules.conf to add ivtv-specific configuration info. For the PVR-250 and M179, as well as PVR-350 users that aren't using its TV-Out (in NTSC land):

Note that successful loading of all modules at startup seems to depend on the ordering of your entries in modules.conf. One user reports that he had to reload ivtv every time after a reboot until placing the entire ivtv section just under the path[toplevel]=/lib/modules/`uname -r` line in his modules.conf.

I'm told that for PAL regions, the tuner type will vary, likely either type 20 or 28. For SECAM, the tuner type is typically 3. The type can be obtained from dmesg after modprobing tveeprom, like so:

For the above PAL example, the resulting modules.conf entries would be:

You might also need to specifiy your audio standard explicitly, as auto-detection in the msp driver isn't always perfect (can result in no audio, or very tinny audio). See http://ivtv.writeme.ch/tiki-view_faq.php?faqId=1#q30 for details.

Users of the PVR-350 will need a few additional settings if they want to enable TV-Out, so their modules.conf additions should look like this for S-Video output:

And like this for PVR-350 Composite video output (the options saa7127 line being the only difference):

NOTE: Most of the PVR-350 TV-Out information contained here is derived from the TvOutHowto on the ivtv wiki site, with slight modifications to be Fedora/Red Hat specific.

PVR-350 TV-Out users: at present, the ivtv-fb module cannot be unloaded (it'll probably crash your system if you try), so if you're debugging, it might be best to comment out the ivtv-fb line in modules.conf. You'll also need to create some additional video devices for the PVR-350 to use once you do load up the ivtv-fb module. Due to differences in the way Red Hat handles device permissions, this command varies a fair amount from the version in the ivtv wiki's TvOutHowto. Anyhow, create the necessary devices with proper permissions using this command (all on one line):

Now try loading up the ivtv driver:

PVR-350 TV-Out users: With the ivtv-fb line in your modules.conf, this will also load up the ivtv-fb module. If you have that line commended out, you can load the ivtv-fb module up manually, with this command:

Check that the card is being properly recognized:

The lspci output should return something like this for a PVR-250 within the output (rev2, iTVC16, thus "Unknown device 0016"):

Or like this for an M179:

And finally, like this for a PVR-350:

Those intending to run X on their PVR-350's output(s) will want to make note of their PCI bus ID, which is the very first part of that lspci output (the 00:07.0 part in the above example), because it'll have to be specified in your XF86Config file.

Also check that your video device(s) exist:

Make a note of what your video device has been set up as (device /dev/video0 in this case), as you will need to inform MythTV of this fact later on. You can determine exactly what device ivtv is configured on by looking in /var/log/dmesg just after loading the module. For example, you should see something like this:

I believe M179 users may see failure messages regarding i2c. I think the primary use of i2c on the PVR-x50 is for the IR interface, which the M179 does not have. I'm not certain on that one though...

PVR-350 TV-Out users: you'll also need to take note of the frame-buffer device that ivtv-fb grabs. You can find that out with this command (followed by example output):

In this case, the PVR-350's TV-Out grabbed /dev/fb0, since there are no other frame-buffer devices loaded on the system. Most likely, you'll either get fb0 or fb1. You'll need to know that for your XF86Config file later on.

PVR-350 TV-Out users: the next step is to test the functionality of the TV-Out connection. First, remove the saa7127 module, so we can subsequently reload it with a test pattern. If you only have one input to your TV at your disposal, and you're already using it with your video card's TVOut, it is perfectly safe to unplug that connection and substitute the 350 for it. Simply switch the connections back when you've seen the 350 test pattern. For an S-Video connection:

And for a Composite video connection:

PVR-350 TV-Out users: If you're using the right output, you should see a test pattern, consisting of several vertical bars of color. If you don't get color, you've got the wrong output type selected, and/or maybe your TV is expecting the other variant (if you're using some sort of adapter to convert from SVid to Composite, which you should NOT do, since the 350 has outputs for both).

PVR-350 TV-Out users: If everything looks good at this point, unload the saa7127 module and reload it without the test pattern:

And for a Composite video connection:

Now you need to set some aspects of the capture card for test capturing. In this case, we're going to make sure the card is set up for tuner input, using the NTSC (US) video standard, and full NTSC resolution (720x480). The next four lines 1) set NTSC as the video standard, 2) select the tuner for input, and 3) set the full NTSC resolution of 720x480 (you can set a lower rez if you really want, but I say use the best! But then I have an HDTV...) and 4) specify the sound input and output channels. NOTE: The ivtv docs say that './test_ioctl -p 0' should set the tuner for input, but yours may vary (mine did, it is '-p 4'). Keep trying with different -p values (I think at least 0-8 are valid for some cards), doing a test capture after each change until you get the right one. You may or may not have to do the same for the 4th line.

And by popular demand, here is the PAL version:

And finally, the SECAM version:

MythTV now controls some (all?) of these functions internally, so be sure to set similar values when we get to the MythTV setup portion. Now hook up your cable or antenna to the WinTV PVR-250's tuner input if you haven't already done so, and we'll try to capture some video... Press Ctrl-C to stop the video capture.

Use that copy of mplayer you installed a bit ago to view the capture:

If you get something that looks and sounds intelligible, then congrats, you've got ivtv video capturing set up!

PVR-350 TV-Out users: to hear audio with this video capture when played back through mplayer, audio output is going to be through your sound card, not the PVR-350's audio outputs. Personally, I piped the 350's audio outputs back into the line in port on my sound card, and then the sound card feeds my speakers, because system, MythMusic and mplayer audio (currently) can only be output through a sound card (but work is underway to change that).

If you get the following error:

Run the following commands to reload the driver (this won't work for PVR-350 users if the ivtv-fb module is loaded -- see above):

Now try the capture again.

If you don't have any sound, it is possible that the correct msp3400 module didn't get loaded for one reason or another. To remedy that situation, follow these steps:

Then reload the driver yet again, and try the video capture one more time:

PVR-350 TV-Out users: now that you have video capture working, we'll try to play some video through the PVR-350's output(s). First, we'll tweak some of the cards settings, then read video in and immediately pipe it out:

PVR-350 TV-Out users: at this point, you need to connect the PVR-350's video output to something you can actually see its output on. For those with a single TV input, once again, you can type the commands in, then move your cables around. Note that sound for this test will be fed out the 350's audio outputs. If you see and hear what you'd expect from television, you're ready to keep moving on, s reset the alpha settings on the card (which MythTV handles internally, so you shouldn't have to do this again):

PVR-350 TV-Out users: if you got video, but there were about 20 evenly spaced horizontal lines overlaying it, try tweaking the ivtv-fb driver with this command:

Then run the dd test again, and with luck, the picture will look like it should. If not, rinse and repeat from the beginning...

Some people have run into issues with their cards generating a slight inverse ghosted image off to the right of the main picture, myself included. The recommended fix, which appears to be working for me, is to set the DNR mode to 0 (mine was initially set to 3), like this:

Also make sure that the values for DNR temporal and spatial filters are set to 0, for best results:

You can verify all the settings for your card, see possible inputs, video standards, etc., with this command:

NOTE: While MythTV has been able to control ivtv capture resolution for some time now, as of version 0.12, MythTV can also control the capture bit rate, so scripts adjusting bit rate are no longer necessary (and will be overridden by MythTV's internal mechanisms).

Running X on the PVR-350's TV-Out-

For starters, recall the PCI bus ID of your PVR-350. Mine was 00:07.0 from the example output above, which is actually a hexadecimal value. What we'll actually need in XF86Config is 0:0x07:0 to get the card properly recognized (it may not matter in this case, since 7 hex = 7 decimal, but it certainly does if your PCI bus ID is something like 00:0f.0).

You can simply download my (ntsc-only) XF86Config file for the PVR-350, edit the PCI bus ID and frame-buffer device lines to match your system. PAL users will have to check out the ivtv wiki TvOutPal HOWTO for PAL-specific info. You can grab my PVR-350 XF86Config file here:

To be on the safe side, I highly recommend making a backup of your current XF86Config file before putting your tailored XF86Config file into place:

Assuming you're still in run-level 5 at this time, connected to your display with your video card's TV-Out, move your cabling and/or switch inputs on your TV over to the PVR-350 and hit ctrl-alt-backspace to kill off X and restart it on the PVR-350. You ought to be greeted by a login screen. If you are, you're in business. If not, you probably did something wrong, so retrace your steps. =)

NOTE: there is more X/TV-Out related info at the start of the ivtv-fb.c file in ivtv/driver if you download the ivtv source code.

Log in as your mythtv user and launch mythfrontend if you don't have it already auto-loading. Go into Settings → TV Settings → Playback and go to the "Use PVR-350 Output" screen. Check the box, and make sure it reads /dev/video16. Click through to the "Finish" button of that section, and now you should be good to go for MythTV to take full advantage of the PVR-350's decoder and TV Output.

General notes and observations from my first few days of using the PVR-350's TV-Out:

• mplayer WILL play back movies through the 350's tv-out, but the processor has to do all the decoding and the sound has to go through your sound card. However, even on an Athlon XP 2400 system, video playback isn't entirely smooth (for high-quality divx rips). Better support for the 350 as an output device is slated for a future mplayer release.
• Trying to use MythGallery locked up the frontend, MythDVD suffers from the same problems as mplayer (until you use a patched mplayer, which I haven't yet tried). I haven't yet tried MythGame or MythMusic.
• On many TVs, the picture is heavily overscanned. I haven't yet tried tweaking the XF86Config mode to see if I can reduce it, though I've seen indications on the mythtv-users mailing list that this may not be something one should attempt. For reference, I'm currently having to manually specify a MythTV window size of something like 632x472, 40 pixel X offset, 8 pixel Y offset, to fit it to the screen. This will vary heavily from TV to TV.
• Thus far, I'm not seeing a monstrous difference between the 350's output and a GF4MX's output (both via SVid), but I would say the picture is a bit sharper in scenes with high motion (I see a soft edge to things w/the GF4MX that are very sharp w/the 350).
• I think the 350's picture is a touch sharper than when I'm feeding my HDTV a progressive-scan signal via my VGA->Component video adapter, but not by a huge amount. The adapter wins hands-down for me though, because of my large divx collection (both because of 350 playback issues and resolution), the far superior readability (yes, I occasionally web browse on it, occasionally use the shell on it, etc., and a progressive-scan signal is WORLDS better for that), and stability
• So far as stability, I hadn't had a single crash of my MythTV system in ages until introducing the 350. Generally, it works great, but I've froze up the frontend a number of times in a few days, caused two or three crashes of the backend (which is on an entirely different machine), and completely hard-locked the system twice (I've been hammering on it pretty good though). At the moment, I'm back to using the output on my GeForce 4 MX, because I'll take stability over a slight picture quality improvement any day. The 350 was slaughtering the high WAF (Wife Approval Factor) MythTV had been enjoying for some time. ;-)

For users of capture cards based on the Brooktree bt848 and bt878 chipsets-

A wide variety of TV capture cards utilize the Brooktree bt848, bt878 and other variants. The particular card I have is an AVerMedia AVerTV Studio, which has a chipset labeled Conexant Fusion 878A (Conexant bought out Brooktree some time ago). My lspci -v output looks like so:

The card was automatically recognized by kudzu (Fedora Core's hardware detection utility) at system boot time after I put the card in the machine, and a basic /etc/modules.conf entry was written for me, and Fedora Core's stock bttv (v0.7.x) was loaded at startup. Everything worked fine in xawtv (once it was configured with the right parameters, i.e. ntsc, us-cable, tv input), and I was able to use it in MythTV. However, I decided to install the very latest bttv driver, 0.9.12, which is v4l2-only (and thus requires a v4l2-patched kernel, such as the ATrpms ones).

To install bttv 0.9.12, you'll first have to enable at-bleeding in /etc/apt/sources.list by adding the following lines:

Then update your apt package listings and install, like so:

At the moment, I recommend promptly disabling at-bleeding after you've installed bttv, as any install or dist-upgrade with at-bleeding enabled will suck in a whole lot of additional possibly less-than-stable packages. Comment out the at-bleeding line you added a minute ago, and then update your package listings again.

While my card works with the single line, "alias char-major-81 bttv", and everything is correctly auto-detected, some more advanced features may not be enabled (such as btaudio) and some cards may not be properly detected. A script that appears to be of some use is ftvco, or Find TV Card Options, which you can find here: http://www.mind.lu/~yg/ftvco/. It'll ask you a few questions, then try a number of combinations, which you can preview in xawtv. Chances are, one of those combinations will work for your card, and then a file is written out with the necessary contents to be placed into /etc/modules.conf.

Side note: btaudio appears to NOT work on my AVerTV Studio card, contrary to reports this card does support btaudio, because no msp34xx chip is ever found (having an msp34xx is a requirement for btaudio). If anyone has input to assist me in forcing bttv to find the chip, I'd appreciate it, since nothing I've tried has worked. Also, note that I am unable to locate a chip on the PCB that says anything like msp34xx, so maybe it was removed in recent versions of this card, I dunno. There are also issues with this card not selecting the right audio channel on stations with SAP sometimes...

Unlike the PVR-x50s, which mux audio in with the video stream into mpeg2 files, and since I can't get btaudio working, I needed an audio jumper cable from the sound out on the TV card to the line in on my sound card. This is all well and good for xawtv, but you need to make a few quick tweaks for use with MythTV. Open up your sound mixer (Fedora/Red Hat menu → Sound & Video → Volume Control) and mark the check boxes for Mute and Record for the Line In on your sound card. Now when you try xawtv, you'll get no sound, but when you fire up MythTV, everything will be gravy. Trust me.

PVR-x50 and bttv-based card in the same system-

Only some minor tweaks are required to get both the PVR-x50 and a bttv-based card running in the same system, provided they have the same tuner type (if they don't, you'll need a hacked ivtv driver, which I can't help you with). I installed everything pretty much along the same lines as above, with the only real difference being my modules.conf. Here is the pertinent section of my modules.conf file:

Note that I had only set up the PVR-250's remote in this dual tuner configuration. The PVR-250 was configured for /dev/video0, the AVerTV for /dev/video1, and both had a type 2 tuner. If you have a second card with a different tuner type, it could be problematic...

Hauppauge WinTV PVR-250 and AVerMedia M179 in the same system-

This is the setup in my current production system. The M179 doesn't always initialize properly at system startup, but always works if I rmmod ivtv, then modprobe ivtv after the system is up and running. Again, my M179 is showing up as /dev/video0 and my PVR-250 as /dev/video1, and I'm using the 21288 firmware. Here is the pertinent section of my modules.conf file:

For users of the pcHDTV capture card-

My card finally arrived, and I have begun working with it. UPDATE: I've had the card for a few months now, but I haven't had much of any time to really play with it still... You're probably better off looking in the pchdtv.com forums for information, but there are a few notes below.

-The custom bttv-based pcHDTV driver will not compile against the latest ATrpms kernel. I reverted to Fedora Core's 2.4.22-1.2174.nptl kernel, and everything compiled just fine.

-Initially, I had the pcHDTV card in a machine with a Radeon 9000 Pro video card. Using the open-source radeon driver, I got magenta artifacts covering the rightmost 10-20% of the picture on all channels that were 1920 pixels in width. It has been suggested to me that it is a problem with the radeon driver's Xv support, and not properly handling sources of that size. I switched to ATI's own fglrx driver, which failed to display ANY video on wide-aspect channels, including the previously perfect ABC, which has a 1280x720 signal in my neck of the woods. To top it off, the fglrx driver hard-locked my dual Athlon MP for the first time ever. (Buh-bye, fglrx).

-I was able to set up MythTV 0.12 and view HD channels within it while using the radeon driver, but was never able to change the channel successfully. Some fixes have already been rolled into recent CVS, and I'll be giving that a shot ever so shortly. With the fglrx drivers, I was never able to watch a single channel. Some X error kept spitting out repeatedly on the console. (Again, buh-bye fglrx).

-Upon swapping in a GeForce 4 MX card, everything looked much better. All channels show up in xine without a problem, no artifacts to speak of. I haven't had a chance to play with it in MythTV just yet. Thus far, my only advice is that you use a GeForce 4 MX or GeForce FX to minimize headaches...

12. Get and install lirc

As of this writing, the final version of lirc 0.7.0 still has yet to be released, and there are issues with it not compiling correctly against the ATrpms kernels, which are now patched with the latest i2c support. However, there is some very good news. We've now got pre-patched lirc rpms available from ATrpms, installable via apt and everything. However, it should be noted that at this time, as downloaded, they don't work with every single remote out there. LIRC is a bit of an ugly beast, in that it has to be recompiled for nearly every type of remote interface, and can't easily be compiled to support all at once, so creating rpms for all remote interfaces would be quite a task. Axel has attempted to roll in as much support for the most popular remotes as possible, and quite a few do now work. It is also possible to obtain the source packages, and rebuild for your specific remote, if the prebuilt packages don't work for you.

The earlier "apt-get install mythtv-suite" command installed part of LIRC for us already. To finish the install, we need the appropriate kernel module as well. Simply install the kernel module like so:

For PVR-x50 users only:

With the kernel module installed, we need to put the correct config file for lirc and the grey Hauppauge remote in place, which is provided by the ivtv folks. Say yes if prompted about overwriting an existing file.

Users with the older black Hauppauge remote, you'll need to go this route (there's some variation in the config files, because the two different remotes have different buttons):

Alternatively, you can also use certain universal remotes with you Hauppauge IR receiver. I'm now using a RadioShack 15-2116 remote to control MythTV. I've done a little write-up on what was required to make it work, complete with config files, which you can find here:

Now we add a bit to ivtv's setup in /etc/modules.conf to load the lirc modules. Find this line of the ivtv module config:

And add this line below it:

Then add one line near the top of /etc/modules.conf, but after this section:

that reads:

To get started with lirc right now, we'll just modprobe...

If everything is still going like it should, let's set up lircd (the lirc receiver daemon) to start at boot time:

And go ahead and fire it up right now...

If you get one or two [OK]'s, then proceed to testing the remote (one is for lircd, one is for lircmd; you only really need lircd). If not, check /var/log/messages to see if you can figure out what went wrong. To begin testing, fire up the irw tool:

You should get some output corresponding to the buttons you pressed. Hit ctrl-C to stop irw.

The next step is to set up a file to map those remote button presses onto key combinations that MythTV understands, so your remote actually does something useful once we have MythTV working. I've got one already prepared and ready for download. You can view it here:

Getting it onto your MythTV box is a simple matter of:

Please be aware that this lircrc file is somewhat customized toward my own needs. For example, the VOL+/- buttons don't alter volume at all, because I use an external amp. However, the MUTE button does mute. Other notables are the YELLOW button, which seeks to the previous commercial cut point, the BLUE button, which seeks to the next commercial cut point, and the FULL button, which toggles the aspect ratio (very useful with my HDTV). Adjusting the buttons to suit your own needs is a simple matter of editing the lircrc file.

For those with bttv-based cards:

There are quite a few different possible remote control interfaces used across the wide array of bttv cards. Many of them SHOULD work with the latest lirc kernel module available from ATrpms, but probably not all. You'll have to do some investigation of your own to figure out which lirc interface type your card uses, but the types that should work are (from the lirc driver types in the rpm spec file):

My AVerTV Studio card uses the avermedia98 lirc driver, and works quite nicely with this rpm. The actual kernel module used is lirc_gpio, so I add this line to my /etc/modules.conf file:

Next, I drop the appropriate lircd.conf file for my remote in place. Config files can be found in /usr/share/doc/lirc-0.7.0/remotes/<your type>. I simply did this:

At this point, I started up lircd:

The start command should return an OK or two (look in /var/log/messages if you don't get an okay for some possible insight as to what went wrong). Now fire up irw to verify that lircd is receiving signals from your remote:

You should see some output when you press buttons on your remote that correspond with each button press. Hit ctrl-C to stop irw.

At this time, you're on your own to create a lircrc file for your remote. I have mostly implemented one for my AVerTV Studio remote, mostly just to verify that it work and until I get something better (quite frankly, it is utter junk, especially for use with MythTV).

Hopefully, this section will be of some aid to those using a different remote interface also...

13. Set up MySQL

We'll need to enable MySQL to load at startup, set some passwords, and create the MythTV database, which we'll populate shortly. Starting with MythTV 0.12, the population of this database is handled by mythtvsetup, in the next step, and all MythTV add-on module database additions must be done AFTER running mythtvsetup.

Set the mysql root password, replacing ROOT_PWD with your chosen administrator password:

Now we create the mythtv database (called mythconverg) to get us started:

Again, all subsequent database population for MythTV's add-on modules must now be done AFTER running mythtvsetup for the first time.

Fedora Core contains a mysqladmin ping check in its mysqld init script, which fails after a password is set for the root account. The check will hang for 10 seconds, and then falsely report a failed mysqld startup. To remedy this, edit /etc/init.d/mysqld as root, changing the two lines that read:

To something like this:

14. Set up MythTV

For those that went with the recommended custom partitioning scheme with a dedicated /video partition and are running an ATrpms kernel, I highly recommend changing that dedicated partition over to XFS, which provides some significant performance gains when dealing with large files (like MythTV recordings). Its optional, but well worth the effort. The steps to do this are actually relatively minor. Check them out in the Miscellanea section below.

There are a number of other things you might want to know to successfully complete setup. First, recall that your video device was set up as /dev/video0. Note that the actual device number is NOT what determines what order MythTV will use your cards in. What matters is the order that you enter them in mythtvsetup, so your best card doesn't have to be /dev/video0. Set up /dev/video8 first, and it'll be the first card used for recordings.

You will also need your zip code (please tell me you know this...), and it would help to know the right listing from http://www.zap2it.com/ (for US users, other countries use different listings sources) that matches your service provider, so xmltv gets the right program listings (I screwed up the first time, because I was guessing, and most of the programming info was askew).

Now on to launching the MythTV setup utility. For this part, you need to have an X session started up, as the setup utility is an X application. Fire it up like so:

WARNING: I'm told that non-US folks may have issues correctly getting through the tv_grab_xx/xmltv part of the setup if "focus follows mouse" is already set (in KDE's Control Center), so keep that in mind. Just set "focus follows mouse" when everything else is already configured.

Recent changes in the mythtvsetup and database population methodology broke the default path settings for the MythTV rpms, which should be /var/lib/mythtv/ for storage of recorded shows, and /var/cache/mythtv/ for live TV buffer. These directories are automatically created at install time, but you'll have to manually enter them in section 1 of mythtvsetup.

Those using a dedicated /video partition, per my example, should obviously set /video/recordings/ for storage of recorded shows and /video/buffer/ for their live TV buffer. However, you can do pretty much whatever you like here, such as recording to an NFS or samba mount, a software RAID array, or even to an LVM group so you can expand your /video partition sometime down the road. Just make sure your mythtv user has permission to read and write to whatever location you choose.

Starting with MythTV 0.12, there is a new profile system that helps to better aid users in properly configuring their video capture cards, so the setup process is rather straight-forward and idiot-proof now (hopefully ;).

It is highly recommended that you go through the setup steps in order. Follow the on-screen instruction, with aid from the MythTV website's documentation on this page:

NOTE: your system may appear to hang at step 3; give it time, it isn't locked up, that part just takes a while!

Once you've gone through the setup, you have to populate the MythTV database with some program info. Personally, I find it useful to take a look at my xmltv file before filling the database, so I can edit out stations I really don't want listed (either because I don't care for them, or they don't actually work). You can open the xmltv file with the text editor of your choice. The location of your file should have been printed out on the console once you exited mythtvsetup, but the file should be /home/mythtv/.mythtv/whatever-you-called-it.xmltv and you can either delete the unwanted lines altogether, or just comment them out with a hash.

Once you have your xmltv file to your liking, fill your database like so:

BE PATIENT! This takes a pretty long time, depending on your internet connection speed and how many channels your service provides... It is also recommended to run mythfilldatabase every night from cron, to keep your show information up to date. To help mitigate possible flooding of our listings provider's servers, we'll set mythfilldatabase to run at some random time after 2:30am, as suggested by David Rees on the mythtv-users mailing list. We'll simply add an entry to the mythtv user's crontab, like so:

When mythfilldatabase is done, start up the MythTV backend, which we'll daemonize a bit later:

Now start up the MythTV front-end...

There are various options within mythfrontend that you can tweak... On setting I would definitely suggest enabling is "De-interlace Playback", even if you're using an interlaced display (like a TV). Just trust me on that one, it'll improve your picture considerably. You're on your own for the rest of the settings. Just be sure to go through every section, and get to the point where you click a "Finish" button, otherwise some values seem to not get initialized (most notably, you may get crashes that say something about not being able to open the dsp). If everything appears to be working, once you've gone through all the configuration steps, you can set your system up to automatically load everything at startup. And congrats, you've done the bulk of the work. You can stop here if you want, but if you're like me, you'll want everything to load automatically when the system boots.

15. Configure automatic startup

The necessary init script for the MythTV backend to automatically start at system boot is already in place for you, just simply turn it on:

If the backend isn't already running, save yourself a reboot and issue this command:

Now set mythfrontend to automatically start on login (there are a couple of ways to do it; I chose this one):

While logged in to an X session, you'll also have to run gdmsetup, to set autologin for your mythtv user. You'll have to get a root terminal open (if you aren't logged into your X session as root already, which is a no-no), then:

In GDM Setup, on the first tab ('General'), you should see a section "Automatic login". Check the box for "Login a user automatically on first bootup" and select your mythtv user from the popup menu. Alternatively, if you are not very comfortable with Linux just yet, and you suspect there may be occasions where you've mucked something up to the point that an auto-login will lock up the computer, you might not want to use Automatic Login. Instead, you might opt to use the "Timed Login" option, to log the mythtv user in a few seconds after the login screen first appears. This way, you can circumvent the mythtv user logging in, and log in as root to hopefully correct whatever you've broken.

I recommend setting the Kicker (the panel at the bottom of the screen) to auto-hide, so it isn't on-screen during video playback, disabling the screen saver, and disabling any monitor-related dynamic power management, or you may not be able to wake your system up if you don't have a mouse and keyboard connected. You can use the KDE Control Center to disable your screen saver, and edit your XF86Config file to disable dpms, but here is a nice, quick and easy method of disabling of dpms and your screen saver:

To turn on auto-hiding of the Kicker, right-click on the Kicker, choose 'Configure Panel...', then select the 'Hiding' tab, and select the radio button for 'Hide automatically'.

16. Configuring MythTV add-ons

When you installed MythTV using apt-get install mythtv-suite, you not only installed MythTV, but also all of the add-on modules currently available. Starting in MythTV 0.13, all database population is done automatically, but there's a bit of setup you still need to do to make them functional...

MythBrowser-

MythDVD-

MythGallery-

MythGame-

MythMusic-

MythNews-

MythVideo-

MythWeather-

MythWeb-

17. Upgrading your system

Upgrading your MythTV installation to a new release is now extremely straight-forward. As of MythTV 0.13, all database changes are handled automagically, so you merely have to upgrade your mythtv rpms when they become available. Occasionally, driver updates are also required (such was the case with the ivtv driver when upgrading to MythTV 0.13, and PVR-350 output in 0.14+ requires ivtv 0.1.9+). The basic upgrade process should be as simple as:

Those without capture cards using the ivtv driver can obviously skip the ivtv line.

A general note about upgrading and installing rpm packages: you should NEVER use --nodeps to install or remove a package. If you can't get around using --nodeps, there is likely a packaging problem, which you should report upstream, to have it fixed. A tanked rpm database can do Very Bad Things™ to your system, and recovery is sometimes impossible. Try 'apt-get check' to verity its integrity, should you happen to have committed the --nodeps sin in the past.

Upgrading your kernel is a little bit more involved than upgrading only MythTV, because all custom kernel modules, both rpm-installed and source-installed, will have to be updated also. Kernel modules carry two different versions, one for the kernel they are for (the 'kernel version') and one for the actual module itself (the 'module version'). Everything but kernels and their matching kernel modules get upgraded automatically by 'apt-get dist-upgrade'. However, note that cases where the kernel version on a kernel module remains the same, but the module version is incremented, an 'apt-get dist-upgrade' will upgrade that kernel module. Essentially, you really only need to take extra measures when upgrading your kernel, as everything else gets handled automatically.

When you do come to a point where you need to upgrade your kernel, one of the nice features of installing from packages, rather than source, shows itself. For all the ATrpms kernel modules, you can simply type in the command...

...to get a full list of all the kernel modules you have installed on your system. With that list in hand, you can now install your new kernel, along with all the corresponding updated kernel modules. For example:

You might also want to install the corresponding kernel-source rpm, especially if you're compiling any kernel modules by hand. You can also uninstall an older kernel and its kernel modules with a single command:

18. Miscellanea

Appearances-

Dedicated XFS-formatted /video partition-

Wide-screen tweaks-

Use native ALSA in MythVideo-

MythVideo/mplayer remote control consistency-

MythVideo focus issue-

Maximizing hard drive throughput-

Graphical boot-

Remote front-ends-

Compiling stuff on your own-

Exporting your recordings to play elsewhere-

Key bindings-

19. CHANGELOG